System for implementing security on telecommunications terminals

ABSTRACT

A system includes at least one telecommunications terminal having data processing capabilities, the telecommunications terminal being susceptible of having installed thereon software applications, wherein each software application has associated therewith a respective indicator adapted to indicate a level of security of the software application, the level of security being susceptible of varying in time; a software agent executed by the at least one telecommunications terminal, the software agent being adapted to conditionally allow the installation of software applications on the telecommunications terminal based on the respective level of security; a server in communications relationship with the software agent, the server being adapted to dynamically calculate the level of security of the software applications, and to communicate to the software agent the calculated level of security of the software applications to be installed on the telecommunications terminal.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to the field of securityenforcement on telecommunications terminals, either mobile or wired, andparticularly to the enforcement of security of the application layer intelecommunications terminals having an open operating system, thatallows the installation (and execution) of third-party softwareapplications.

2. Description of Related Art

The diffusion and evolution of mobile telecommunications terminals(e.g., mobile phones of the last generation), in terms of computationalpower of the terminal, available communication bandwidth, availabilityof services and of software applications specifically designed for thetelecommunications terminals, is widening the breadth of the servicesthat the telecommunications terminals can make available to the users,and the modalities of accessing the telecommunications networks.

Nowadays, the availability of communication bandwidth and ofcomputational power on mobile telecommunications terminals with an openoperating system like Windows Mobile, Symbian, or SavaJe, has made itpossible to offer new added-value services, and the adoption of “alwayson” connectivity profiles (i.e., the user of the telecommunicationsterminal is always connected to a telecommunications/data communicationsnetwork, and can at any time access the offered services). Examples ofthese new services are the unified messaging (e-mail, instant messaging,Short Messaging Service—SMS—, Multimedia Messaging Service—MMS), secureaccess to enterprise's resources over IP (Internet Protocol) channels bythe employees (for example by means of protected tunnels with protocolslike TLS/SSL—Transport Security Layer/Secure Socket Layer—, IPsec—IPsecurity—, L2TP—Layer 2 Tunnel Protocol—and the like), services ofDigital Rights Management (DRM), access and exploitation of multimediacontents (based for example on the DVB-H—Digital VideoBroadcasting-Handheld standard), access to enterprise's services andapplications, and so on.

The availability of these powerful mobile telecommunications terminalsis a great market opportunity, also considering the broad target ofcustomers that can be reached by customized offers. However, suchpowerful terminals bring about security issues also in connection withthe core business of the mobile telecommunications network operator. Themobile terminal is, under several respects, particularly vulnerable tosoftware attacks: just to cite some examples, the mobile terminal isusually devoted to a personal use, it stores sensitive information (bothof personal and of professional nature), it has a money creditassociated with the SIM (Subscriber Identity Module), it storesinformation (like the IMSI—International Mobile Subscriber Identity—andthe IMEI—International Mobile Equipment Identity) that allows an easytracking of the user, it has access to wide communication bandwidth(e.g., GPRS/EDGE/UMTS), and it may implement different types ofconnectivity (like for example Wi-Fi, Bluetooth, IrDA—Infrared DeviceApplication—, NFC—Near Field Communication, ZigBee).

Today, the security issues that involve mobile telecommunicationsterminals are mainly due to the sensitivity of the user (SocialEngineering), and the diffusion of Trojan-type malware. A user of amobile phone usually is less sensitive to security issues compared, forexample, to a user of a Personal Computer (PC); this is in part due tothe higher diffusion of mobile phones compared to PCs, and to the factthat a phone is generally perceived as a secure device, so users are notaccustomed to consider that their mobile phones may be subject tosoftware attacks.

Nowadays, the circulating malware is essentially of the Trojan type;thus, it rarely exploits the vulnerability of the software resident onthe mobile terminal, rather it uses a “cover” application for installingon the terminal, after having obtained the user's authorization (and inthis respect the low sensitivity of the user plays an important role),and then perpetrating the attacks for which it is designed (for examplesending SMS to premium numbers, deleting user files and documents,illegally forwarding e-mail and other types of messages, replicatingitself).

Several initiatives have been promoted for finding solutions to theincreasing demand for higher security, driven in part by the diffusionof several malware applications. Some of the most important initiativesare the Microsoft Mobile-2-Market(http://msdn.microsoft.com/mobility/windowsmobile/partners/mobile2market/default.aspx),Symbian Signed (http://www.symbiansigned.com), OMTP (Open MobileTerminal Platform) P6 Application Security Project(hftp://www.omtp.org), GSM-A MAS (Mobile Application Security) Project(http://www.gsmworld.com/using/security/mobile_application.shtml), JavaMIDP (Mobile Information Device Profile) 2.0(http://java.sun.com/products/midp/index.jsp).

In general, all the known initiatives are based on a same model,hereinafter referred to as the “trust model”, which generally definestwo macro-categories of software applications that can run on a mobiletelecommunications terminal: trusted applications and non-trustedapplications.

Non-trusted applications are digitally unsigned applications (orapplication digitally signed by untrusted Certification Authorities—CAs)whose genuinity cannot be assessed on the terminal when they areinstalled and/or executed; these applications are thus a potentialsource of attacks to the terminal, because there is no information aboutthem and it is not possible to perform any check. For these reasons,non-trusted applications are allowed to access only a limited subset ofresources of the telecommunications terminal, i.e. of APIs (ApplicationProgram Interfaces), exposed by the operating system, namely APIs thatare not considered dangerous.

Trusted applications are instead digitally signed (by trusted CAs), andare allowed to access a wider set of exposed APIs. In particular, theAPIs exposed by the operating system are grouped in different classes,according to a criterion of criticality of the accessed resources. Thetrusted, digitally signed applications are mapped onto a certainsecurity level based on the CA that issued the digital certificate withwhich the application has been signed. Different security levels aredefined, corresponding to different “root certificates”: an applicationis certified with respect to a certificate chain which refers to one ofthe root certificates present on the terminal. The security level to beassigned to the application is determined on the basis of the securitylevel assigned to the root certificate used during the phase ofverification. The security level assigned to the application determinesthe set of resources that the application can access, and the way theapplication can interact with them. In some cases, an application havingbeen assigned a certain security level does not gain access to all theresources specified for that level, but only to those specified by thesoftware vendor during the certification process.

The use of the digital signature mechanism further allows implementingan application revocation mechanism, when the applications arecompromised or violate specific security policies. For example, in caseof availability of connectivity, the mobile terminal, before installingand/or executing an application, may ascertain whether the consideredapplication has been revoked; this may be done by downloading andchecking a Certificate Revocation List (CRL), or exploiting protocolslike the Online Certificate Status Protocol (OCSP), so as to get animmediate response about the validity of the certificate tied to thesigning key, and therefore of the related signed application.

An example of implementation of the trust model can be found inEP-A-1361527 in which a method is described for loading an applicationinto a device, and generally for downloading applications into portabledevices, typically mobile telephones. The method includes the steps of:downloading the application with a signature to the device; coupling thesignature of the application to a predefined attribute certificatestored in the device; and installing the application together with saidattribute certificate. Preferably, the signature of the application iscoupled to a root certificate which in turn is linking the applicationto a predefined attribute certificate.

Another example of implementation of the trust model can be found in WO2006/017757 in which a method and an apparatus are disclosed forproviding enhanced security using service provider authentication. Inaddition to authenticating an application signature against a rootcertificate stored on the network node, a first carrier identificationassociated with the application is compared to a second carrieridentification. If the first and second carrier identifications match,then the application can be assigned to a trusted protection domain andgranted permissions which provide privileged access to the network node.For example, the application can be granted permission to be installedand/or executed on the network node. Otherwise the application can bedenied privileged access. Accordingly, a carriers applications will beonly installed onto network nodes that are intended recipients of theapplications.

Still another example of implementation of the trust model can be foundin US 2005/03398 in which a single machine has entities running in anuntrusted environment and entities running in a trusted environment, thetrustworthiness of the entities in the trusted environment is projectedto the entities in the untrusted environment. This is applicable, forexample, to Microsoft's Next Generation Secure Computing Base (NGSCB),where a regular operating system (e.g., the Windows operating system)hosts a secure operating system (e.g., the nexus).

SUMMARY OF THE INVENTION

The Applicant has observed that the trust model discussed in theforegoing is affected by some problems.

The certification of applications by CAs has a non-negligible cost;thus, only those software producers/vendors capable of sustaining thecertification costs will more likely be able to stay on the market(i.e., to offer powerful applications capable of accessing the mostinteresting APIs exposed by the operating systems of the mobileterminals). In this respect, it should be observed that the costs forhaving software applications certified by CAs are high also because itis not sufficient to have an application certified the first time it isput on the market: the certification needs to be repeated for each newrelease of the application, even if the changes are few or if a servicepack or an application patch is released by a vendor.

The problem of certification costs is particularly felt in the case ofopen-source software: the Applicant believes that it would be importantthat also open source-software applications may gain access to all theAPIs and resources of operating systems, but the adoption of theabove-described trust model, based on certification by CAsm may renderthis impossible, because it is not clear who will sustain the costs ofthe certification.

Another problem of the trust model resides in the application revocationmechanism mentioned above. The revocation of an application could orshould be authorized by several players involved within the trust model,like mobile phone users, software producers/vendors, network operators,mobile terminals manufacturers, and this complicates the design of theprocess and the assignment of the different roles and responsibilities.Legal issues are also involved, due to the different legislations indifferent countries: this may make it difficult to create a uniqueframework globally recognized and legally supported by the differentcountries adapted to offer a homogenous service profile.

Still another problem of the trust model is that a software applicationis assigned a certain security level based on a set of standard tests,involving a static analysis of the application code (i.e., an analysisthat does not consider what the application would actually do whenrunning in the real environment). However, this static analysis may notbe very effective: it cannot reconstruct and evaluate all the possibleexecution paths of the application. For this reason, some certificationprocesses, like Symbian Signed, require a declaration from the softwareproducer about the non-malicious behavior of the application. Thesituation is even more complex when software vulnerabilities areconsidered (bugs of software applications that may be exploited by themalware for propagating and making damages). Determining, through astatic analysis, the presence of vulnerabilities is nowadays achallenging problem. Known solutions like Java, Symbian Signed,Microsoft M2M provide for a static assignment of a security level to theapplications, determined during the certification phase. This kind ofcertification, as well as other types like Common Criteria or ITSEC(Information Technology Security Evaluation Criteria) certification,does not prevent the application from containing serious vulnerabilitieswhich can be exploited by malicious software to perform attacks.Moreover, the certification does not change even if a criticalvulnerability is determined and one or more exploits have been released.This static assignment is considered by the Applicant a stronglimitation, both for the users (restrictions on the usability of thesoftware applications) and for the business models that can beimplemented.

In view of the state of the art outlined in the foregoing, the Applicanthas tackled the problem of implementing a security scheme not affectedby the problems and limitations discussed above.

In particular, the Applicant has tackled the problem of increasing thesecurity of the application layer in telecommunications terminals havingan open operating system.

The Applicant has found that the problems evidenced by the known trustmodel can be overcome by providing a framework adapted to assign tosoftware applications, that are installed and, possibly, executed by thetelecommunications terminals, levels of security susceptible of varyingin time, and by providing a framework adapted to dynamically manage theassigning of the levels of security to the applications.

In particular, the Applicant has found that the levels of security canbe assigned based on a reputation of the software applications. Byreputation of a software application there is meant the degree of trustof the software application. The reputation, i.e. the degree of trust ofa software application, may be calculated based on information gatheredfrom a plurality of information sources; the information useful forcalculating the reputation of a software application may includeinformation about number and gravity of discovered vulnerabilities,analysis of the software application code (executable and, possibly,source code), existence of exploits of the discovered vulnerabilities,time to release of patches, and the like.

For the purposes of the present invention, by “vulnerability” there ismeant a weakness in a data processing system, allowing an attacker toviolate the integrity, confidentiality, access control, availability,consistency or audit mechanism of the data processing system, or thedata and/or applications it hosts. Vulnerabilities may result from bugsor design flaws in the system. A vulnerability can exist either only intheory, or could have a known exploit. Vulnerabilities are particularlycritical when the program containing the vulnerability operates withspecial privileges, performs authentication or provides easy access touser data or facilities.

The dynamic calculation of the level of security of the softwareapplications may be delegated to a server entity, operating on behalf ofthe users of the telecommunications terminals.

According to an aspect of the present invention, a system as set forthin appended claim 1 is provided.

The system comprises:

-   -   at least one telecommunications terminal having data processing        capabilities, the telecommunications terminal being susceptible        of having installed thereon software applications, wherein each        software application has associated therewith a respective        indicator adapted to indicate a level of security of the        software application, said level of security being susceptible        of varying in time;    -   a software agent executed by the at least one telecommunications        terminal, said software agent being adapted to conditionally        allow the installation of software applications on the        telecommunications terminal based on the respective level of        security;    -   a server in communications relationship with the software agent,        said server being adapted to dynamically calculate the level of        security of the software applications, and to communicate to the        software agent the calculated level of security of the software        applications to be installed on said telecommunications        terminal.

For the purpose of the present invention, by “level of security” of asoftware application there is intended a degree of trust that can beattributed to the software application, which determines the extent towhich a telecommunications terminal allows access to its resources (APIsof the operating system).

According to a second aspect of the present invention, atelecommunications terminal as set forth in claim 19 is provided, havingdata processing capabilities, and being susceptible of having installedthereon software applications, wherein each software application hasassociated thereto a respective indicator adapted to indicate a level ofsecurity of the software application. The telecommunications terminalcomprises a software agent, adapted to be executed by thetelecommunications terminal, said software agent being adapted toconditionally allow the installation of software applications on thetelecommunications terminal based on the respective level of security,and to receive from a server updated levels of security of the softwareapplications to be installed on said telecommunications terminal.

According to a third aspect of the present invention, a system as setforth in appended claim 26 is provided, comprising a server adapted tocommunicate with at least one telecommunications terminal having dataprocessing capabilities, wherein the telecommunications terminal issusceptible of having installed thereon software applications, eachsoftware application having associated therewith a respective indicatoradapted to indicate a level of security of the software application,said level of security being susceptible of varying in time, said serverbeing adapted to dynamically calculate the level of security of thesoftware applications, and to communicate to the software agent thecalculated level of security of the software applications to beinstalled on said telecommunications terminal.

According to a fourth aspect of the present invention, a method as setforth in appended claim 36 is provided, comprising conditionally allowan installation of a software application on a telecommunicationsterminal based on the a level of security of the software application.Said level of security is susceptible of varying in time, and the methodfurther comprises having the telecommunications terminal receive anupdated level of security of the software application by a server incommunications relationship with the telecommunications terminal.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present invention will be madeapparent by reading the following detailed description of an embodimentthereof, provided merely by way on non-limitative example, descriptionthat will be conducted making reference for better clarity to theattached drawings, wherein:

FIG. 1 schematically shows, in terms of functional blocks, thearchitecture of a system according to an embodiment of the presentinvention;

FIG. 2 schematically shows, in terms of functional blocks, the structureof a trust provider component of the system of FIG. 1;

FIG. 3 schematically shows, in terms of functional blocks, the structureof a client component of the system of FIG. 1, resident on a terminal;

FIGS. 4A, 4B and 4C show a simplified flowchart illustrating the mainactions performed by the client component and the trust providedcomponent in case of installation of a new software application on theterminal; and

FIG. 5 shows a simplified flowchart illustrating the main actionsperformed by the client component and the trust provided component incase a software application installed on the terminal is launched.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Making reference to the drawings, in FIG. 1 the architecture of a systemaccording to an embodiment of the present invention is schematicallyshown, in terms of functional blocks.

The system is comprised of a trust provider component 105, operating asa server in respect of several client components 110, resident on mobiletelecommunications terminals 115-1, 115-2, 115-3, 115-4, 115-5 of users.

The mobile communication terminals are for example mobile phones, PDAs(Personal Digital Assistants), smart phones, adapted to the use inmobile telecommunications network, particularly mobile telephonynetworks like GSM (Global System for Mobile communications), GPRS(General Packet Radio System), EDGE (Enhanced Data rate for GSMEvolution) or UMTS (Universal Mobile Telecommunications System)networks. It is however pointed out that although in this descriptionreference is made to mobile communications terminals, this is not to beconstrued as a limitation of the present invention, which applies aswell to wired telecommunications terminals.

The generic mobile terminal 115-1, 115-2, 115-3, 115-4, 115-5 hasinstalled thereon an open operating system, like Windows Mobile,Symbian, or SavaJe, that controls the operation of the mobile terminalsand allows the installation on the mobile terminals of third-partysoftware applications. These software applications that may be installedon the mobile terminal may access the resources of the mobile terminalthrough APIs exposed by the operating system (APIs correspond toresources of the mobile terminal, thus hereinafter the terms “API” and“resource” will be regarded as synonyms).

In particular, the APIs exposed by the operating system are grouped indifferent classes, corresponding to different level of relevancy of theAPIs for the mobile terminal security.

The software applications to be installed and executed on the mobileterminal have an associated security or trust level, that determines theset of APIs (one or more classes) that the application can access, andthe relating access modality.

Typically the security or trust level is one of a plurality of greaterthat two values, corresponding to three of more sets of APIs that theapplication can conditionally access.

Examples of access modalities are the “allow always” modality, the“blanket” modality, the “one shot” modality and the “session” modality.In the “allow always” modality, the access request to a resource (i.e.,to an API) by the software application is essentially transparent forthe user, without requesting any direct interaction with the user(direct interactions may be through a prompt or the Graphical UserInterface—GUI). In the “blanket” access modality, the softwareapplication may again access the resource in a way transparent to theuser, exception made for the first time that the application requestsaccess to the resource: in this case, an explicit authorization by theuser is required; once the authorization is granted, it is consideredpermanent, and the successive access requests to the resource areimplicitly considered authorized. In the “one shot” modality, each timethe application requests the access to the resource, the user has toauthorize it. In the “session” modality the access to the resource needsthe authorization by the user; however, once the authorization isgranted, it is considered valid for the whole session, i.e. until theexecution of the application is terminated or the terminal is kept on;at the next invocation of the application, or at the next terminal powerup, a new authorization by the user will be necessary to grant access tothe resource.

According to an embodiment of the present invention, the security levelthat is assigned to the generic software application intended to beinstalled and, possibly, successively executed on the mobile terminals115-1, . . . , 115-5 is not static, i.e. it is not determined once andfor all, as normally occurs during the application certificationprocess, but it is intended to vary dynamically.

In particular, the trust provider 105 acts on behalf of the users of themobile terminals 115-1, . . . , 115-5, and contributes to maintainingthe integrity of the mobile terminals, by dynamically determining theappropriate security level to be assigned to the software applicationsintended to be installed or already installed on the mobile terminals115-1, . . . , 115-5, and communicating to the mobile terminals theupdated security level of the software applications that areinstalled/to be installed thereon.

The role of the trust provider 105 may be played by the operator of themobile telecommunications network of which the users of the mobileterminals 115-1, . . . , 115-5 are subscribers. In fact, the mobilenetwork operator already acts as a security provider for its users, interms of authentication, channel encryption, and privacy protection.Moreover, it has the necessary technological and managing skills, it istrusted by the users, who already have signed contracts for the accessto the mobile network, and it has resources and platforms, both on thenetwork side and on the mobile terminal side, which may beadvantageously exploited for realizing a security framework.

The trust provider 105 is in communications relationship with the mobileterminals 115-1, . . . , 115-5. Communications between the trustprovider 105 and the mobile terminals 115-1, . . . , 115-5 may inparticular take place OTA (Over The Air), exploiting the mobiletelecommunications network resources, for example via SMS messagesand/or MMS messages, and/or via a packet-based (e.g., GPRS) connectionover an IP network. Preferably, the communications between the trustprovider 105 and the mobile terminals 115-1, . . . , 115-5 areprotected, for example using a digital signature mechanism (e.g., signedXML).

The trust provider 105 is also in communications relationship withexternal information sources, globally denoted 120, adapted to provideinformation useful to the trust provider 105 for dynamicallydetermining, i.e. keeping updated the security level of the monitoredsoftware applications. In particular, and merely by way of example, theexternal information sources 120 may include the CERT (ComputerEmergency Response Team, http://www.cert.org/), denoted as 120-1, whichis a center of Internet security expertise, located at the SoftwareEngineering Institute, a federally funded research and developmentcenter operated by Carnegie Mellon University, devoted to study Internetsecurity vulnerabilities, research long-term changes in networkedsystems, and develop information and training to help improve security;another exemplary external information source is OVAL (OpenVulnerability and Assessment Language, http://oval.mitre.org/), denotedas 120-2, which is a standard language and methodology used to representconfiguration information of systems for testing, aimed at analyzing thesystem for the presence of specified machine state (vulnerability,configuration, patch state, etc.). Further exemplary externalinformation sources are the CVE (Common Vulnerabilities and Exposures,http://cve.mitre.org/), denoted as 120-3, which is a standardizeddictionary for all the publicly known vulnerabilities and securityexposures, the software vendors bulletins, denoted as 120-4, where thesoftware producers and vendors publish the detected vulnerabilities oftheir software applications, possibly together with patches orwork-around resolving the problem, and the software certificationlaboratories, i.e. the CAs, globally denoted as 120-5, which are incharge of testing and certifying the applications, according to wellknown schemes (such as Symbian Signed, Microsoft Mobile-2-Market or OMTPframework).

The trust provider 105 may also be in communications relationship withone or more other trust providers 105-1, 105-2, for example run bydifferent mobile telecommunications network operators, in order to shareinformation relevant to dynamically and timely determining the securitylevel of the monitored software applications. This kind of data can beshared without any privacy concern, because security levels are tied toapplications and not to users.

In FIG. 1, the arrows between pairs of mobile terminals 115-1, . . . ,115-5 are intended to represent direct peer-to-peer telecommunicationschannels between the mobile terminals, for example, but not limited to,short-range communications channels, like Bluetooth, ZigBee, NFC and thelike, or full IP channels over GSM/GPRS/UMTS/HSDPA (High Speed DownlinkPacket Access)/WiFi, if available; in a preferred embodiment of thepresent invention, the mobile terminals, exploiting these direct,peer-to-peer communications channels may share the information relatingto the security level of the software applications installed andpossibly running thereon, even without the need to establish aconnection with the trust provider 105. This contributes to increasingthe efficiency of the security framework and provides better bandwidthconsumption.

Passing now to FIG. 2, the structure of the trust provider 105 isdepicted in greater detail, in terms of the main functional blocks.

The trust provider 105, which acts as a server component in respect ofthe client components 110 installed and running on the mobile terminals,includes a front end 205 and a back end 210.

The front end 205 includes communication interfaces, denoted globally215, for the communication with the clients 110 resident on the mobileterminals; such communication interfaces 215 include for example an SMSinterface, an MMS interface, an IP interface, a broadcast channelinterface (for instance to send information over the Cell Broadcastchannel on GSM/GPRS/UMTS networks). The front end 205 of the trustprovider 105 also comprises an information publishing interface 220,e.g. a web server accessible by third parties, like the users of themobile terminals and the other trust providers, through web browsers;through the information publishing interface 220, the trust provider 105publishes and makes accessible to third parties information like: themethodology adopted by the trust provider 105 to calculate the securitylevel of the monitored software applications (this may take the form ofa Security Level Evaluation Statement—SLES, a document intended todeclare the security level evaluation methodology adopted); a list ofmonitored software applications with their current security levels, and,possibly, historical data concerning how the security level of theapplications varied in time; past events relevant to the establishmentof the security level of the monitored software applications. The accessto this kind of information may be subject to an authentication process,in order to make the data available only to the authorized users andagents.

The back end 210 comprises a static or binary analyzer module 225,adapted to perform a static, i.e. binary analysis of the code of thesoftware applications; a vulnerability analyzer module 230 is alsoprovided, which, exploiting the information gathered from the externalinformation sources 120, is adapted to analyze the vulnerabilities ofthe software applications. A security level evaluator module 235 isconfigured to receive the outputs of the binary analyzer module 225 andthe vulnerability analyzer module 230, as well as to gather informationfrom the external information sources 120, particularly from softwareproducer/vendor bulletins 120-4, from CAs 120-5 and from other trustproviders 105-1, 105-2 and, applying a predetermined metric (specifiedin the SLES published and maintained by the trust provider 105),calculates the security level to be assigned to each monitored softwareapplication. The security level is typically selected by the securitylevel evaluator module among three or more levels. A softwareapplication database 240 is configured to store a list of all thesoftware applications monitored by the trust provider 105, and thecorresponding security levels (preferably, in addition to the currentsecurity level, the past security levels are also stored, so that thehistory of the software applications can be appreciated). A userdatabase 245 stores the identifier and other details (e.g., detailsnecessary for establishing communications with the users' mobileterminals or for billing purposes) of users that are subscribers to thetrust provider 105, and, for each user, a list of software applicationsthat are installed on the users mobile terminal.

In FIG. 3 the structure of the client component 110 installed andrunning on the generic mobile terminal is depicted, in terms of the mainfunctional blocks.

The client component 110 is a software agent running on the mobileterminals. The client component 110 includes a client/servercommunications module 305, adapted to manage the communications betweenthe client component 110 and the server component represented by thetrust provider 105. A peer-to-peer communications module 310 ispreferably provided, adapted to manage the direct communications withother mobile terminals, exploiting for example short-rangecommunications channels like Bluetooth, ZigBee, NFC, and the like, orfull IP communications channels, over GSM/GPRS/UMTS/HSDPA. Moreover, abroadcast communications module 315 is also provided, in order to getinformation through the broadcast radio channels, such as the CellBroadcast in the GSM/GPRS/UMTS network. The communications modules 305,310, and 315 form a front end 320 of the client component 110.

The client component 110 also includes a monitor layer 323. The monitorlayer 323 includes an application installation monitor module 325,adapted to detect the launching of activities related or leading to theinstallation of new software applications on the mobile terminal. Themonitor layer 323 also includes an application execution monitor module330, adapted to detect the launching of applications installed on themobile terminal. A kernel module 335 is provided, that communicates withthe application installation monitor module 325 and the applicationexecution monitor module 330, and with a local database 340 configuredto contain information like the current security level of the softwareapplications installed on the mobile terminal, and the digitalcertificates of the trust provider 105 (possibly, the digitalcertificates of trust providers, like the trust providers 105-1 and105-2, that are federated with the trust provider 105 arecross-certified; in this way, information about the security levels ofsoftware applications obtained, through the peer-to-peer communicationschannels, from mobile terminals that are subscribers to the other trustproviders 105-1, 105-2 of the federation may be validated and recognizedas both genuine and approved by the user's trust provider).

The kernel module 335 also interacts with a security level updatermodule 337, which manages the updating of the security levels of thesoftware applications, establishing communications with the trustprovider 105 (through the client/server communications module 305)and/or with other mobile terminals (through the peer-to-peercommunications module 310), or just receiving updated information bymeans of broadcast radio channels, such as the Cell Broadcast (throughthe broadcast communication module 315).

The kernel module 335 may also communicate with external informationsources (where by “external” there is meant external to the clientcomponent 110, but resident on the mobile terminal), like an IntrusionDetection System (IDS) 345 and other security tools 350, for example ananti-malware software or a personal firewall installed on the mobileterminal.

In the following, the operation of the security framework will beexplained in detail.

The trust provider 105 maintains updated a dynamic level of security ofthe software applications installed on the mobile terminals of the usersubscribers thereto.

Referring to the simplified flowchart of FIGS. 4A, 4B and 4C, let it beassumed that, at a certain time, a new software application is to beinstalled on the mobile terminal: in this case the event is detected bythe application installation monitor module 325 (block 405), whichnotifies it to the kernel module 335 (block 410). The kernel module 335,upon receiving the notification from the application installationmonitoring module 330, looks into the local database 340 to ascertainwhether the specified software application is already listed therein(meaning that the application is already monitored), and, in theaffirmative case, it checks whether the security level of the softwareapplication is sufficiently up to date (decision block 415). In theaffirmative case (decision block 415, exit branch Y), the kernel module335 assesses whether the security level of the software application tobe installed is sufficiently high, i.e. it is not below a predetermined,minimum security level (decision block 420): in the affirmative case(decision block 420, exit branch Y), the kernel module authorizes theinstallation of the application (block 425), which will therefore beallowed; in the negative case (decision block 420, exit branch N), thekernel module 335 may prevent the installation of the softwareapplication. It should be noted that the predetermined minimum securitylevel may be optional: if not configured, the application will be alwaysinstalled on the mobile terminal, and just limited, in terms ofavailable mobile terminal APIs, by its corresponding security level.

In case the specified software application to be installed is not listedin the local database 340, or, even if it is listed, the security levelthereof is not sufficiently up to date (decision block 415, exit branchN), the kernel module 335 invokes the security level updater module 337to inform the server component that a new application is going to beinstalled on the mobile terminal, and to get the (updated) securitylevel for the considered application (block 435).

The security level updater module 337 tries to establish a connectionwith the trust provider 105 (block 440) and, if the connection issuccessfully established, it informs the trust provider 105 that theinstallation of a new software application has been started on themobile terminal. It also asks the trust provider 105 for the updatedsecurity level related to the specified software application (block445).

The trust provider 105 receives the request from mobile terminal (block450), updates the user database 245 adding the specified softwareapplication to the list of applications installed on the mobile terminalof the user (block 455), and then provides to the security level updatermodule 337 the current security level for the specified softwareapplication (block 460). In case the specified software application isnot in the list of the monitored software applications, the trustprovider can start a procedure for gathering information on thatsoftware application, and for calculating the corresponding securitylevel. According to the specific metric adopted by the trust provider,the security level computation for a new application (i.e., anapplication not already monitored) may require time, and thus it mayhappen that it cannot be completed in real-time. In these cases, thetrust provider can return a conservative security level (for instancethe lower value), in order to limit the set of the APIs available to theapplication, at least for the time needed to complete the full securitylevel computation. In these cases, the trust provider may also ask otherfederated trust providers for the security level related to the specificapplication.

The updated security level for the specified application is passed tothe kernel module 335, and stored into the local database 340 (block465).

The kernel module 335 can now assess the security level of the softwareapplication to be installed, and allows or prevents the installationdepending on whether the security level of the application is below apredetermined, minimum security level (connector C, jumping back todecision block 420).

The security level updater module 337, in case the connection with thetrust provider 105 cannot be established, or in addition to establishinga connection with the trust provider 105, may try to establish aconnection with other mobile terminals, using the peer-to-peercommunications module 310. If the security level updater module 337cannot establish any kind of connection (for instance because the mobileterminal is offline), according to a preconfigured policy, the kernelmodule 335 may assign either a conservative security level (for instancethe admissible lower level) or prevent the software installation untilan updated security level for the considered application will beavailable.

Referring to the simplified flowchart of FIG. 5, let it now be assumedthat, at a certain time, a software application installed on the genericmobile terminal 115-1 is launched. The application execution monitormodule 330 detects this event (block 505), and notifies it to the kernelmodule 335 (block 510). The kernel module 335, upon receiving thenotification from the application execution monitor module 330, checksif the application is already installed and monitored, i.e. if theapplication is already present in the local database 340. If theapplication is not present, the event is handled as an installation of anew application, as described in connection with FIGS. 4A to 4C. Ifinstead the application is present in the local database 340, the kernelmodule 335 retrieves the associated security level from the localdatabase 340. If the security level is sufficiently up to date, thekernel module 335 grants the execution and the API access to theapplication, based on its security level. Conversely, if the securitylevel is not sufficiently up to date, the kernel module 335 invokes thesecurity level updater module 337 in order to refresh the security levelinformation stored in the database 340 (block 515).

The security level updater module 337 tries to establishes a connectionwith the trust provider 105 (block 520), and if the connection isestablished it asks to the trust provider 105 to provide the updatedsecurity level for the specified software application (block 525). Thesecurity level updater module 337, in case the connection with the trustprovider 105 cannot be established, or in addition to establishing aconnection with the trust provider 105, may try to establish aconnection with other mobile terminals, using the peer-to-peercommunications module 310.

The trust provider 105 receives the request from the mobile terminal,and provides thereto the current security level for the specifiedsoftware application (block 530), taking it from the applicationdatabase 240. Possibly, the trust provider 105, upon ascertaining thatthe specified software application is not in the list of softwareapplications installed on the mobile terminal of that user, adds it tosuch a list (stored in the user database 245). In case the connectionwith the trust provider cannot be established, or in addition thereto,the mobile terminal may receive an updated security level for thespecified application from one or more other mobile terminals; in thiscase, the security level updater module 337 may be adapted to assesswhich is the more recent security level for that software application:this may for example be done by associating, with the security level, anindication of the date and time the security level was last updated.

The updated security level is passed to the kernel module 335, andstored into the local database 340 (block 535).

If the security level updater module 337 cannot establish any kind ofconnection (for instance because the mobile terminal is offline),according to a preconfigured policy, the kernel module 335 may assigneither a conservative security level (for instance the admissible lowerlevel) or prevent the software execution until an updated security levelfor the considered application will be available.

Based on the security level, the kernel module 335 grants to thesoftware application that has been launched conditional access to theresources of the mobile terminal, i.e. to the APIs exposed by theoperating system associated to the specific application security level,according to the trust model implemented.

When a software application is uninstalled from the mobile terminal of auser, this event is communicated to the trust provider 105 (as soon as anetwork connection is detected and available), which then deletes thespecified software application from the list of software applicationsinstalled on the mobile terminal of that user, stored in the userdatabase 245.

The trust provider 105 may also implement push-type update mechanisms ofthe local database 340 of the mobile terminals (for instance by means ofSMS, MMS, WAP push messages, Cell Broadcast messages), so as to provideto the client components 110 running on the mobile terminals updatedsecurity levels of the software applications installed thereon. Also,the client components, in addition to inquiring the trust provider 105when a software application is launched or is being installed on themobile terminal, may periodically contact the trust provider 105 to getupdated security levels for the software applications installed thereon.In alternative or in addition to the periodical updating, the clientcomponent may operate on a sample basis, selecting a subset ofapplications among those installed on the mobile terminal (for instancethe most frequently used) and for them requesting the updated securitylevel.

The client components 110 resident on the mobile terminals may alsonotify to the trust provider 105 anomalous events, detected for exampleby IDS or anti-malware tools 345 or 350 installed on the mobileterminal. Upon receiving such notifications, the trust provider may takethe steps necessary to identify which of the software application(s)installed on the mobile terminal caused the anomalous events (forinstance correlating the anomalous events sent by different users), andput the identified applications in a list of applications that need tobe more carefully analyzed; these applications may for example be testedin depth in laboratory.

Hereinafter an example of a method implemented by the trust provider 105for calculating the security level of the software applications isdiscussed. It is pointed out that the calculation method described belowis merely exemplary, and not to be construed limitatively for thepresent invention, because several alternative methods are possible.

The binary analyzer module 225 is adapted to analyze statically thebinary code of the generic software application. The static analysis isperformed statically analyzing the executable code, without analyzingall the possible dynamic behaviors or the execution paths of thesoftware application. The static analysis may in particular ascertainthe type of the APIs that the software application invokes, details ofthe installation of the software application (e.g., if the autorunfeature is exploited), the nature of the accessed data. Based on theanalysis performed, the binary analyzer module 225 may assign a value toa parameter or set of parameters AS to be passed to the security levelevaluator module.

The vulnerability analyzer module 230 is adapted to assess thevulnerabilities of a software application whose security level is to beevaluated. The vulnerability analyzer module 230 is adapted to retrieveinformation useful for assessing the vulnerabilities from externalinformation sources like the CERT, the OVAL/CVE, the bulletins of thesoftware producers and vendors, the software certification authorities.The vulnerability analyzer module 230 is adapted to provide to thesecurity level evaluator module 235 an indication of the overall numberof vulnerabilities found for the considered software application, thelevel of criticality of each encountered vulnerability, and anestimation of when the next criticality will be found, by means ofstatistical and predictive analyses. Based on the analysis performed,the vulnerability analyzer module 230 may assign a value to a parameteror set of parameters AV to be passed to the security level evaluatormodule.

Another parameter that is useful to the security level evaluator modulefor establishing the security level of an application is the reactiontime of the software producer/vendor to the detection/publication of anew vulnerability, i.e. the indication of the time needed by thesoftware producer/vendor for finding a remedy to the detected/publishedvulnerability. A parameter or set of parameters TR may be defined whosevalue depends on the time needed for the publication of a remedy after avulnerability is detected/published, the efficacy of the publishedremedy, workaround or patch, the criticality of the vulnerability towhich the remedy has been published.

The security level evaluator module may additionally assign a value to aparameter or set of parameters AF defining the reliability of thesoftware producer/vendor; in this way, enterprises that, in theirhistory, have proved to be capable of producing/distributing secure,reliable software products affected by less vulnerabilities may beprivileged.

In the process of evaluating the security level of a certain softwareapplication, the trust provider 105 may further take into account thepresence of any certification, declaration or assurance, issued by arecognized authority, such as those related to Symbian Signed, MicrosoftMobile2Market, Common Criteria, or ITSEC. The presence of such acertification may affect the value of a parameter or set of parametersAC.

A further source of useful information for determining the securitylevel of a software application are the notifications coming from themobile terminals themselves, for example anomalies detected by anomalydetection or intrusion detection tools resident on the mobile terminals.As mentioned in the foregoing, when an IDS or an anti-malware softwaretool resident on the generic mobile terminal detects an anomalybehavior, or just an intrusion, by a malware, they may signal it to theclient component 110, which then notifies the event to the trustprovider 105 (possibly conditioned to the authorization of the mobileterminal user). The trust provider, knowing which are the softwareapplications that are installed on the mobile terminal of that user, cancarry out an analysis to identify, by correlating the informationpossibly coming from different mobile terminals, which is the softwareapplication(s) that most likely caused the anomaly. The trust providermay also perform more detailed analysis such as a static analysis of thecode or blackbox analysis (i.e., analysis that do not make assumptionson the implementation choices made during the development of a softwareapplication, limiting to observe and analyze the inputs and outputs ofthe application). This type of analysis affects the value of a parameteror set of parameters AD.

In the evaluation of the security level to be assigned to a softwareapplication, the trust provider may also set a time window for theanalysis, for example considering the number of vulnerabilities detectedand published in the last predetermined number (e.g., twelve) months.The set time window is specified as the value of a parameter t.

Using the above discussed evaluation elements, the metric adopted by thesecurity level evaluation module for calculating the security level of asoftware application may be expressed as:

SL _(APP)(t)=ƒ(AS,AV,TR,AF,AC,AD,t)

where ƒ( ) denotes a function having a predetermined form, and AS, AV,TR, AF, AC, AD and t are parameters that correspond to the evaluationelements described above.

Depending on the case, the trust provider may apply one among aplurality of functions ƒ( ), for example based on the type of user. Forexample, a function ƒ_(Consumer)( ) should be defined for consumer usersthat do not want to give up the possibility of installing and executinga generic software application on their terminals. Another functionƒ_(Enterprise)( ) should be defined for users employees of a customerenterprise, having stricter security standards.

A possible function ƒ( ) is a weighted sum of the parameters:

${{SL}_{APP}(t)} = \frac{\begin{matrix}{{\omega_{AS}{{AS}(t)}} + {\omega_{AV}{{AV}(t)}} + {\omega_{TR}{TR}(t)} +} \\{{\omega_{AF}{{AF}(t)}} + {\omega_{A\; C}A\; {C(t)}} + {\omega_{A\; C}A\; {D(t)}}}\end{matrix}}{\omega_{AS} + \omega_{AV} + \omega_{TR} + \omega_{AF} + \omega_{A\; C} + \omega_{A\; C}}$

where the weights may be differentiated based on the type of users:

Ω_(Consumer)=(ω′_(AS),ω′_(AV),ω′_(TR),ω′_(AF),ω′_(AC), ω′_(AD))

Ω_(Enterprise)=(ω″_(AS),ω″_(AV),ω″_(TR),ω″_(AF),ω″_(AC), ω″_(AD))

these being two sets of weight factors specific for consumer users andfor enterprise users, respectively.

The present invention overcomes the problems of current staticcertification systems, in terms of high costs and organization.

Thanks to the present invention, software applications are assignedsecurity levels that may vary dynamically in time, being periodicallyre-calculated by means of a well recognized evaluation metric so as totrack changes in the security aspects of software applications; thisallows implementing policies that rewards software applications thathave demonstrated on the field their security.

Moreover, the present invention contributes to reduce the security risksassociated to both malware and exploitable applications. Once a malwareis detected, the corresponding security level is an information for theagent on the mobile terminal to prevent the application from running(and possibly to delete it). In case of an exploitable application, thesecurity level is lowered until a work around or a patch will bereleased, making the application executable, but at the same timelimiting is the resources made available on the mobile terminal. Thislimit is put in order to also reduce the risk of damages produced bymalware which exploits the application vulnerability. It should be notedthat, within this period (up to the work around or the patch) theapplication is still available to users.

The solution according to the present invention is very flexible,particularly in terms of the business models that can be set up; thecosts for keeping the security level information available at the mobileterminal updated may for example be sustained by the trust provider,that may set up toll-free telephone numbers for the connection theretoby the mobile terminals of subscriber users; in case the role of thetrust provider is played by the mobile network operator, these costs maybe included in the service agreement with the users.

The system according to the present invention enables the mobiletelecommunications network operators to play a central role in theenforcement of security on the mobile terminals, and this is believed tobe advantageous not only for the operators themselves (in terms ofnetwork protection), but also for the users, who can rely on a trustedcounterpart having the technical and organizational skills.

Another advantage of the system according to the present invention isthat it does not exclude an important category of applications likethose falling under the open source software category, because thesoftware producers are not required to sustain high certification costs.

The system according to the present invention can be easily integratedwith existing solutions, based for example on the previously describedtrust model.

The present invention has been herein described making reference to anexemplary and non-limitative embodiment thereof. Those skilled in theart will recognize that several modifications can be made to thedescribed embodiments, for example in order to satisfy contingent needs, as well as several other embodiments are possible, without departingfrom the scope of protection set forth in the appended claims.

For example, nothing prevents from implementing the software agent inthe SIM to be operatively associated with the telecommunicationsterminal for its operation in the telecommunications network.

1-39. (canceled)
 40. A system comprising: at least onetelecommunications terminal comprising data processing capabilities, thetelecommunications terminal being susceptible of having installedthereon software applications, wherein each software application hasassociated therewith a respective indicator adapted to indicate a levelof security of the software application, said level of security beingsusceptible of varying in time; a software agent executed by the atleast one telecommunications terminal, said software agent capable ofbeing adapted to conditionally allow the installation of softwareapplications on the telecommunications terminal based on the respectivelevel of security; and a server in communications relationship with thesoftware agent, said server being adapted to dynamically calculate thelevel of security of the software applications, and to communicate tothe software agent, the calculated level of security of the softwareapplications to be installed on said telecommunications terminal. 41.The system of claim 40, wherein said software agent further comprises anadaptation to: detect an incipient activity of installation of asoftware application on the mobile telecommunications terminal; andrequest to the server an updated security level with respect to thesoftware application to be installed.
 42. The system of claim 40,wherein the telecommunications terminal is further susceptible ofexecuting software applications installed thereon, said software agentfurther comprising an adaptation to conditionally allow the softwareapplications, when executed on the telecommunications terminal, toaccess telecommunications terminal resources based on the level ofsecurity of the software application being executed.
 43. The system ofclaim 42, wherein said telecommunications terminal resources compriseapplication program interfaces exposed by an operating system governingthe operation of the telecommunications terminal.
 44. The system ofclaim 42, wherein the software agent further comprises an adaptation to:detect the launching of a software application installed on the mobiletelecommunications terminal; and request from the server an updatedsecurity level with respect to the software application being launched.45. The system claim 44, wherein said software agent further comprises alocal database adapted to store the security levels of the softwareapplications installed on the telecommunications terminal.
 46. Thesystem of claim 45, wherein said software agent further comprises anadaptation to request from the server the updated security level withrespect to the software application being launched on condition that asecurity level stored in the local database for the software applicationis not up to date.
 47. The system of claim 40, wherein said servercomprises: a first module adapted to perform a static analysis of thecode of the software applications; and a second module adapted toperform an analysis of vulnerabilities exhibited by the softwareapplications.
 48. The system of claim 47, wherein said first modulecomprises an adaptation to perform said static analysis by assessing atype of telecommunications terminal resources invoked by the softwareapplications.
 49. The system of claim 47, wherein said first modulecomprises an adaptation to perform said static analysis by assessing amodality of installation of the software applications on thetelecommunications terminal.
 50. The system of claim 47, wherein saidfirst module comprises an adaptation to perform said static analysis byassessing a type of data accessed by the software applications.
 51. Thesystem of claim 47, wherein said second module comprises an adaptationto perform said analysis of vulnerabilities based on an indication of anoverall number of known vulnerabilities detected for the softwareapplications.
 52. The system of claim 47, wherein said second modulecomprises an adaptation to perform said analysis of vulnerabilitiesbased on a degree of criticality of the detected vulnerabilities. 53.The system of claim 47 wherein said second module comprises anadaptation to perform said analysis of vulnerabilities based oninformation obtained from one or more among the computer emergencyresponse team, the open vulnerability and assessment language, and thecommon vulnerabilities and exposures bulletins of the softwareapplications producers/vendors, and software certification authorities.54. The system of claim 40, wherein the server comprises: a firstdatabase adapted to store a list of software applications monitored bythe server, and a respective level of security.
 55. The system of claim54, wherein the server comprises: a second database adapted to store alist of software applications installed on the at least onetelecommunications terminal.
 56. The system of claim 40, furthercomprising at least a second telecommunications terminal, the softwareagent being adapted to receive from said second telecommunicationsterminal information related to the level of security of said softwareapplications.
 57. The system of claim 40, wherein said software agentfurther comprises an adaptation to: gather information from one or moreanti-malware software applications or an intrusion detection systemrunning on the telecommunications terminal; and communicate the gatheredinformation to said server, said server further comprising an adaptationto: receive from the telecommunications terminal the gatheredinformation; and use the received information for dynamicallycalculating the security levels of software applications.
 58. Atelecommunications terminal having data processing capabilities, thetelecommunications terminal being susceptible of having installedthereon software applications or executing software applicationsinstalled thereon, wherein each software application has associatedtherewith a respective indicator adapted to indicate a level of securityof the software application, comprising: a software agent, adapted to beexecuted by the telecommunications terminal, said software agentcomprising an adaptation to at least one among; conditionally allow theinstallation of software applications on the telecommunicationsterminal; and conditionally allow the software applications, whenexecuted on the telecommunications terminal, to accesstelecommunications terminal resources based on the respective level ofsecurity, and to receive from a server updated levels of security of thesoftware applications to be installed or executed on saidtelecommunications terminal.
 59. The telecommunications terminal ofclaim 58, wherein said software agent further comprises an adaptationto: detect an incipient activity of installation of a softwareapplication on the mobile telecommunications terminal or detect thelaunching of a software application installed on the mobiletelecommunications terminal; and request to the server an updatedsecurity level with respect to the software application to be installedor of the software application being launched.
 60. Thetelecommunications terminal according to claim 59, wherein said softwareagent further comprises a local database adapted to store the securitylevels of the software applications installed on the telecommunicationsterminal.
 61. The telecommunications terminal of claim 60, wherein saidsoftware agent, further comprises an adaptation to request from theserver the updated security level with respect to the softwareapplication being launched on condition that a security level stored inthe local database for the software application is not up to date.
 62. Aserver comprising an adaptation to communicate with at least onetelecommunications terminal having data processing capabilities, whereinthe telecommunications terminal is capable of having installed or runthereon software applications, each software application havingassociated therewith a respective indicator adapted to indicate a levelof security of the software application, said level of security beingcapable of varying in time, said server comprising an adaptation todynamically calculate the level of security of the softwareapplications, and to communicate to the software agent the calculatedlevel of security of the software applications to be installed or run onsaid telecommunications terminal.
 63. The server of claim 62 comprising:a first module adapted to perform a static analysis of the code of thesoftware applications; and a second module adapted to perform ananalysis of vulnerabilities exhibited by the software applications. 64.A method comprising: conditionally allowing an installation or executingof a software application on a telecommunications terminal based on alevel of security of the software application, said level of securitybeing capable of varying in time; and having the telecommunicationsterminal receive an updated level of security of the softwareapplication by a server in communications relationship with thetelecommunications terminal.